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I METHOD OF REPRESENTING ROAD LANES 
2 

3 REFERENCE TO RELATED APPLICATIONS 

4 This present application is a continuation-in-part of the copending patent 

5 application Serial No. 10/465,890, entitled "METHOD OF REPRESENTING ROAD 

6 INTERSECTIONS," filed June 19, 2003, the entire disclosure of which is incorporated 

7 herein by reference. 
8 

9 BACKGROUND OF THE INVENTION 

10 The present invention relates to methods for representing roads as data in a 

I I database and more particularly, the present invention relates to methods for representing 

12 road lanes in a database used for vehicle driver assistance systems. 

13 Vehicle driver assistance systems, such as systems for obstacle warning and 

14 avoidance, lane departure warning, collision warning and avoidance, adaptive cruise 

15 control, adaptive transmission operation, automatic headlight aiming, and so on, have 

16 been developed to improve the safety and convenience of vehicle operation. These 

17 systems include technologies that augment a driver's ability to operate a vehicle safely 

18 and efficiently. Some of these systems include equipment that senses features around the 

19 vehicle. In addition, some of these systems use data that models the road network upon 

20 which the vehicle is traveling. Based on the sensed features and the model of the road 

21 network, the driver assistance and safety systems may provide warnings or otherwise 

22 modify operation of the vehicle to improve safety or convenience. 

23 Data representations of the road network have also been used for various other 

24 purposes. For example, data representations of the road network are used in vehicle 

25 navigation systems to provide navigation-related features, such as route calculation, route 

26 guidance, map display and destination selection. In some databases used by navigation 
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1 systems, each road segment is represented by one or more data records or entities. 

2 Associated with each data record or entity are attributes that describe various features of 

3 the represented road segment. Some of the features of a road segment that are 

4 represented by such data records include the location of the road segment, the locations 

5 of road intersections, the name of the road segment, the speed limit (or speed category) 

6 along the road segment, the number of lanes along the road segment, any highway 

7 designations of the road segment, the type of road surface (e.g., paved, unpaved, gravel), 

8 the presence of any lane dividers, etc. 

9 The ways that roads are represented in databases used in navigation systems are 

10 useful. However, the ways that roads are represented in databases used for navigation 

1 1 purposes may not be suitable for driver assistance and safety systems. For example, for 

12 navigation purposes, it is important to have data that indicate the speed limits along 

13 roads, the names of roads, the address ranges along road segments, and how much time it 

14 might take to cross a road intersection. For navigation purposes, the exact path that a 

15 vehicle takes along a road segment is not necessarily important unless the vehicle is 

16 approaching an upcoming maneuver. However, for driver assistance systems, such as 

17 obstacle avoidance or waming systems, the paths that vehicles take along a road segment 

18 may be needed to provide a waming or take another action. 

19 Accordingly, it is an objective to provide a data model for roads, and in particular 

20 for lanes along roads, that can be used by driver assistance systems. 

21 It is another objective to provide a data model for road lanes that is compatible 

22 with various uses of the data. 
23 

24 SUMMARY OF THE INVENTION 

25 To address these and other objectives, the present invention includes a method 

26 and system representing road lanes as data in a database that can be used by a system in a 

27 vehicle to provide a safety-related function. Each data representation of a physical road 

28 lane includes data indicating start and end points of the represented lane and other data 

29 attributes pertaining to the represented lane, including data indicating what physical 

30 features are adjacent to the represented lane on right and left sides thereof and data 
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1 indicating a geometry of the represented lane. Further, at least some of the data 

2 representations of lanes are associated with data representations of sublanes. Each data 

3 representation of a sublane includes data indicating start and end points thereof, defined 

4 relative to the lane of which the sublane is a part. A data representation of a sublane 

5 includes at least one data attribute associated therewith that pertains to the represented 

6 sublane and that is different than the same attribute of the lane of which the sublane is a 

7 part. The database is compatible with navigation-related applications that use a different 

8 data model to provide navigation-related functions. 
9 

10 BRIEF DESCRIPTION OF THE DRAWINGS 



1 1 Figure 1 is an illustration of an exemplary intersection located in a geographic 

12 area. 

13 Figure 2 is a block diagram that shows components of driver assistance systems in 

14 the vehicle shown in Figure 1 , 

15 Figure 3 is a block diagram that shows components of an embodiment of the road 

1 6 database of Figure 2. 

17 Figures 4A and 4B are illustrations of overlapping lanes. 

18 Figure 5 is an illustration of a sublane and a data representation thereof 

19 Figure 6 is a block diagram that shows components of one of the intersection 

20 objects shown in Figmre 3. 

21 Figure 7 is an illustration of an intersection showing several transversals thereof 

22 from some of the lanes that lead into the intersection. 

23 Figure 8 is an illustration of an intersection in which the transversals are 

24 instantaneous. 

25 Figure 9 shows the intersection depicted in Figure 7 with several valid vehicle 

26 paths for a transversal of the intersection from one lane to another, illustrating that the 

27 transversal has a low confidence rating. 



28 
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1 DETAILED DESCRIPTION OF THE 

2 PRESENTLY PREFERRED EMBODIMENTS 

3 1. EXEMPLARY ROAD SEGMENT 

4 A first embodiment relates to a method for representing roads, and in particular 

5 road lanes, in a database that contains data that represent a road network in a geographic 

6 region. The database is used by a system in a vehicle that provides safety or convenience 

7 features to the vehicle driver, 

8 Figure 1 shows an exemplary road segment 10, which is part of a road network 

9 located in a geographic region. The road segment 10 is comprised of a portion of a road 

10 between two adjacent intersections 12 and 14. Other road segments (not shown) connect 

11 to the intersections 12 and 14. The road segment 10 can be accessed by a vehicle firom 

12 the other road segments via intersections 12 and 14. 

13 The road segment 10 has several lanes in each direction. For example, the road 

14 segment 10 includes lanes 18, 20, 22, and 24 extending between the intersections 12 and 

15 14. The lanes 18 and 20 are designed to carry vehicle traffic only in the direction from 

16 the intersection 12 to the intersection 14 and the lanes 22 and 24 are designed to carry 

17 vehicle traffic only in the direction from the intersection 14 to the intersection 12. 

18 In addition, the road segment 10 includes some lanes that do not extend the entire 



19 length between the intersections 12 and 14. For example, the road segment 10 includes a 

20 left turn lane 28 leading into the intersection 14 and another left turn lane 30 leading into 

21 the intersection 12. These left turn lanes 28 and 30 extend only part of the way along the 

22 road segment 10. In addition, the road segment 10 includes a right tum lane 34 leading 

23 into the intersection 14. The right tum lane 34 extends only part of the way along the 

24 road segment 10. 

25 The road segment 1 0 is one of many road segments that form the road network in 

26 the geographic region. The other roads segments may have different shapes and may 

27 have more lanes or fewer lanes. 
28 
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1 n. DRIVER ASSISTANCE SYSTEMS 

2 A vehicle 40 travels on the road segment 10. Although only one vehicle is shown 

3 in Figure 1 , the vehicle 40 is representative of many vehicles, which are similarly 

4 equipped, that travel on the roads in the geographic region. Referring to Figure 2, the 

5 vehicle 40 includes one or more driver assistance or safety systems 44. The driver 

6 assistance systems 44 are systems that make operation of the vehicle safer or more 

7 convenient. The driver assistance systems 44 may include an obstacle waming system, a 

8 lane departure waming system, an adaptive cruise control system, and/or a coUision 

9 avoidance system. The driver assistance systems 44 may include other systems in 

10 addition to, or instead of, any of these systems. 

1 1 The driver assistance systems 44 are combinations of hardware and software 

12 components. The driver assistance systems 44 use sensors 48. Various different types of 

13 sensors may be used. Some of the sensors 48 measure (or are responsive to) a property, 

14 parameter, attribute, or characteristic of the vehicle or the environment around the 

15 vehicle. For example, the sensors 48 may include a radar system 48(1), a camera system 

1 6 48(2), or other sensors. 

17 The vehicle 40 includes a positioning system 50. In the embodiment shown in 

18 Figure 2, the positioning system 50 is part of the driver assistance systems 44. 

19 Alternatively, the positioning system 50 may be part of another system in the vehicle 40, 

20 such as a navigation system 5 1 . According to another embodiment, the positioning 

21 system 50 may be a standalone system in the vehicle. The positioning system 50 is a 

22 combination of hardware and software components. For example, the positioning system 

23 50 may include a GPS or DGPS unit 50(1), one or more inertial sensors 50(2), such as a 

24 gyroscope or accelerometer, differential wheel sensors, or other types of equipment. 

25 In a present embodiment, the driver assistance systems 44 include or use a road 

26 database 60. The road database 60 includes a data representation of the road network in 

27 the geographic region in which the vehicle 40 is traveling. In a present embodiment, the 

28 road database 60 includes data that indicate the positions of the roads, the intersections of 

29 roads, and the locations of lanes, as well as other information. 
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1 The road database 60 is used by an application 50(3) in the positioning system 50 

2 to determine the position of the vehicle 40 relative to the road network. More 

3 specifically, the positioning application 50(3) uses the data in the road database 60 and 

4 outputs from other positioning system components, such as the GPS unit 50(1) and 

5 sensors 50(2), to determine the position of the vehicle along a road segment represented 

6 by data in the road database 60, the position of the vehicle relative to the lanes of the 

7 represented road segment, the direction and/or bearing of the vehicle along the 

8 represented road segment, and possibly other parameters. 

9 The driver assistance systems 44 include driver assistance applications 52. The 

10 driver assistance applications 52 are programs that implement the functions of the driver 

11 assistance systems 44. The driver assistance applications 52 receive outputs from the 

12 sensors 48. The driver assistance applications 52 also use data from the road database 60. 

13 The driver assistance applications 52 may also receive other information. Based on the 

14 data received from the sensors 48, the data obtained from the road database 60, and 

15 possibly other information, the driver assistance applications 52 evaluate whether a 

16 warning or other action should be provided. The driver assistance systems 44 provide the 

17 safety or convenience features via a user interface 62 of the vehicle or by controlling a 

18 vehicle mechanical system 64. For example, a curve warning application may provide an 

19 audible alarm via speakers (i.e., part of the user interface 62 in the vehicle) or an obstacle 

20 avoidance application may engage the vehicle's brakes (i.e., one of the mechanical 

21 systems 64 in the vehicle). 
22 

23 m. ROAD DATABASE 

24 Figure 3 shows components of the road database 60. In the embodiment shown in 

25 Figure 3, roads are represented in different ways. These different ways relate to how the 

26 road data are used. The different ways that the road data are used affect which aspects of 

27 a road are represented. For example, in Figure 3, the road database 60 includes 

28 navigation data 80 and physical configuration data 82. (In addition to navigation data 80 

29 and physical configuration data 82, the road database 60 may include other collections of 

30 data that represent the roads in other ways.) In Figure 3, the navigation data 80 and the 
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1 physical configuration data 82 are indicated as being separate collections of data that are 

2 related to each other. However, in alternative embodiments, these different ways of 

3 representing roads may be included in a single collection of data. 

4 The navigation data 80 are used by navigation-related applications, such as route 

5 calculation, route guidance, destination selection, and map display. The navigation data 

6 80 represent the aspects of roads that are important for these functions, such as which 

7 roads connect to each other, road names, speed limits along roads, address ranges along 

8 roads, and so on. 

9 In the embodiment of Figure 3, the navigation data 80 include data that represent 

10 road segments 84 and data that represent nodes 86. In the embodiment of Figure 3, each 

1 1 discrete segment of each road is represented by a separate road segment data record. A 

12 road segment is a portion of a road between adjacent intersections or between a dead end 

13 and an adjacent intersection. A road segment may also be defined that ends at a point 

14 along a road between adjacent intersections. The navigation data 80 in the road database 

15 60 may also include data records that represent aggregations of individual road segments. 

16 A node refers to an endpoint of a road segment. For example, each road segment 

17 has two endpoints. Each endpoint of a road segment is represented with a node data 

18 record 86 the road database 60. 

19 As stated above, the road network database 60 also includes physical 

20 configuration data 82. The physical configuration data 82 are used by the driver 

21 assistance systems (44 in Figure 2) for safety and convenient features, such as obstacle 

22 avoidance, curve warning, adaptive cruise control, and so on. The physical configuration 

23 data 82 provides a representation of the road network that is different from the 

24 representation provided by the navigation data 80. For example, the physical 

25 configuration data 82 represent detailed physical aspects of the road lanes (including lane 

26 size and configurations), detailed aspects of intersections (including locations of vehicle 

27 paths through intersections), traffic signals (and placement thereof), shoulder locations, 

28 and other detailed aspects relating to roads and other physical features. 
29 
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1 IV. REPRESENTATION OF ROAD LANES 

2 Referring to the embodiment shown in Figure 3, the physical configuration data 

3 82 includes data representations of lanes and data representations of intersections. The 

4 physical configuration data 82 may also include data representations of other types of 

5 features as well. 

6 In this embodiment, the physical configuration data 82 includes a separate lane 



7 data entity (or record) 90 for each lane of each road in the geographic region. The lane 

8 data entity 90 includes a data entity ID that uniquely identifies the lane data record in the 

9 road database 60. Each lane data entity 90 identifies which road the lane is part of (e.g., 

10 by reference to a road segment ID in the navigation data 90) and the location of the lane 

1 1 (e.g., the starting location, the ending location). 

12 The present embodiment takes into account that on the actual road network, some 

13 lanes form or end gradually over a longitudinal distance. Examples of gradually forming 

14 lanes are shown at 132 and 134 in Figure 1. In the physical configuration data 82, lane 

15 data entities 90 are used in the road database 60 to represent whole portions of road lanes. 

16 A whole portion of a road lane includes that part where both edges of the lane are 

17 discemable and the lane is at fiiU width. In the physical configuration data 82, a portion 

18 of a lane where the lane is at less than fiiU width is not modeled as a lane, i.e., with a lane 

19 data record. Instead, a portion of a lane where the lane is at less than full width is 

20 modeled relative to the adjacent lane fi-om which the partial lane is gradually forming (or 

21 merging into). A data attribute of the adjacent lane (or lanes) is used to indicate that a 

22 lane is starting or ending adjacent thereto. This way of modeling of gradually forming or 

23 merging lanes is compatible with the relative uncertainty associated with the paths for 

24 cars entering or leaving a lane that is forming or ending. A lane centerline is not 

25 provided for a partial width lane (i.e., where a lane is starting or ending gradually over a 

26 longitudinal distance). The data representation of gradually forming (or merging) lanes is 

27 described in more detail below in connection with the adjacency attributes. 

28 The following considerations relate to the way lanes are represented in the 

29 physical configuration data 82. 

30 (1). Lanes are represented so that they do not cross one another. 
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1 (2). A lane is represented so that it goes up to, but not through, the intersection 

2 at the end of the road segment of which it is a part. (This prevents any implied 

3 connectivity between lanes that is not consistent with reality.) 

4 (3). An actual road lane may continue unbroken across multiple road 



5 segments, such as when a ramp splits off from (one lane of) the road. However, when a 

6 lane is represented in the physical configuration data 82, the lanes of each road segment 

7 are modeled separately. In other words, a lane, as represented in the physical 

8 configuration data 82, does not extend beyond the end of the road segment of which it is 

9 apart. 

10 In the embodiment of Figure 3, the physical configuration data 82 is compatible 

1 1 with the navigation data 80. This allows navigation-related applications (in the 

12 navigation system 5 1 in Figure 2) to be compatible with driver assistance applications (44 

13 in Figure 2). This compatibihty is supported in the road database 60 by including 

14 references between the navigation data 80 and the physical configuration data 82. For 

15 example, a representation of a lane in the physical configuration data 82 may refer to 

16 (e.g., by data record ID) the data record in the navigation data 80 that represents the road 

17 segment of which the lane is a part. 



18 In the physical configuration data 82, the lane data record 90 includes various 

19 attributes 92 that describe features and/or aspects of the represented lane. Some of the 

20 attributes 92 of a lane include a "direction of travel*', the "type of lane", a "validity 

21 period" and "access characteristics." 

22 Some of the different types of lanes include a "through lane", a "left turn lane", a 



23 "right turn lane", a "center tum lane", a "left shoulder", a "right shoulder", a "merge", 

24 and a "ramp." The lane type "left shoulder" or "right shoulder" are used with a "vaUdity 

25 period", as explained below. Full-time shoulders are not coded as lanes. "Left shoulder" 

26 and "right shoulder" are defined with respect to the driver's orientation. In a present 

27 embodiment, some combinations are allowed (e.g., through, left tum, and/or right tum 

28 can all be applied to the same lane at the same time). 

29 The lane attribute "validity period" is used when a lane has different uses at 

30 different times (e.g., a shoulder that is used for through traffic at certain hours). 
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1 The lane attribute "access characteristics" mcludes a "yes/no" indicator for 

2 different vehicle types, such as autos, buses, taxis, trucks, bicycles, pedestrians, 

3 emergency vehicles, carpools, deliveries, through-traffic, and so on. 

4 Additional lane attributes 92 may include road condition, roadside barrier, toll 



5 booth, lane marker type, road surface type, lane width, speed, and adjacency. (The 

6 adjacency attribute is described in more detail below.) If two lanes split, an attribute may 

7 be included that indicates that these lanes overlap. In the case of a true lane split, two 

8 lanes are modeled such that their centerlines start at the same point. These are attributed 

9 as "overlapping" to indicate that two lane surfaces share some of the same pavement. 

10 One example of overlapping lanes is shown in Figure 4 A. Figure 4A shows three lanes 

1 1 on three different road segments. The road segments (and lanes) in Figure 4A connect in 

12 a Y-shaped configuration. Overlapping lanes can occur on a single road segment. An 

13 example is shown in Figure 4B. 

14 In the physical configuration data 82, each data lane data entity 90 is associated 

15 with data 1 12 that defines the geometry of the lane. The geometry of a lane includes the 

16 longitudinal shape of the lane. For purposes of defining the longitudinal shape of a lane, 

17 a centerline of the lane is determined and used to represent the longitudinal shape. A data 

1 8 representation of a lane 90 includes data that defines the lane centerline for every whole 

19 portion of a road lane. The centerline is defined as the line midway between the lane 

20 edges. Lane edges can be lane markings (such as paint) and/or physical edges (such as a 

21 curb, median or edge of pavement). Defining lanes in this manner facilitates 

22 representation of lanes by making the data creation process reliable and reproducible. 



23 The shape of the lane centerline can be expressed in various ways. Some of these 

24 ways include parametric curvatures or sets of shape points interpolated by straight line 

25 segments (e.g., a "polyline"). Examples of parametric curvatures include, but are not 

26 limited to, uniform B-splines, non-uniform B-splines, and clothoids. 

27 The physical configuration data 82 includes data 116 that provides for defining 

28 attributes that apply to only a longitudinal subset of a lane. A longitudinal subset of a 

29 lane is referred to as a "sublane." In the physical configuration data 82, a sublane is 

30 defined by a pair of points along the lane, expressed as distances along the lane centerline 
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1 fiom one end (e.g., a designated end) of the lane. In the embodiment of Figure 3, a 

2 sublane is not defined to have geometry of its own. Instead, the geometry of the lane — 

3 of which the sublane is a part — is applied to the sublane. Defining sublanes in this 

4 manner allows attributes to begin and end as necessary along a lane without complicating 

5 the underlying lane geometry. 

6 When a sublane is defined, the attributes associated with the sublane supersede 

7 those same attributes of the associated lane. For example. Figure 5 shows a physical lane 

8 122 that has left and right shoulders 124 and 126 except for a portion 128. The portion 

9 1 28 has a right shoulder, but on the left side has a barrier, hi the physical configuration 

10 data 82, this lane would be represented by a lane data entity 129 that includes adjacency 

1 1 attributes that indicate that the lane 122 has shoulders on both sides. The lane data entity 

12 129 would mclude roadside barrier attributes that indicate that the lane has no barriers on 

13 either side. In addition, a sublane data entity 131 would be defined for the lane 122. The 

14 sublane data entity would indicate a starting point and an ending point along the lane. 

15 The sublane data entity 131 would include adjacency attributes that indicate that the lane 

16 has no drivable surface on the left side. In addition, the sublane data entity 131 would 

17 include roadside barrier attributes that indicate that the lane has a roadside barrier on the 

18 left side. Thus, for that portion of the lane 122 that corresponds to the sublane 128, the 

19 attributes of the sublane data entity 131 would apply instead of the attributes of the lane 

20 data entity 129. 

21 In a present embodiment, only those fields of a sublane data entity are populated 

22 that are different fi-om the corresponding fields in the lane data entity that represents the 

23 lane of which the sublane is a part. Accordingly, in Figure 5, the sublane data entity does 

24 not contain any information regarding the adjacency or barrier on the right side because 

25 the right-side adjacency and barrier situation of the sublane is not different than on the 

26 rest of the lane. 

27 Several considerations apply to sublanes. A sublane does not extend past the end 

28 ofthelaneofwhichitisapart. Multiple sublanes may be defined for each lane. 

29 Sublanes may overlap each other, except that sublanes that overlap cannot change the 

30 same lane attributes. Sublanes that do not overiap may change the same lane attributes. 
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1 Another of the attributes 92 associated with the data representation of lanes 90 is 

2 data that indicates what is next to the represented lane on each side thereof. In one 

3 embodiment, each lane data entity 90 includes adjacency attributes 140. The adjacency 

4 attributes 140 indicate what lies to the left and right of a represented lane beyond the lane 

5 boundary. This attribute can be applied to the whole lane and also to a longitudinal 

6 subset of the lane (a "sublane"). 

7 The adjacency attribute may include data that indicate any of the following 



8 


conditions: 




9 


(1). 


another lane, which can be entered by a lane change, 


10 


(2). 


another lane but which cannot be entered, 


11 


(3). 


a lane that is in the process of forming, 


12 


(4). 


a lane that is in the process of ending. 


13 


(5). 


a shoulder, 


14 


(6). 


another "drivable surface", e.g., not a lane or shoulder, but a surface that 


15 


might have a vehicle on it, such as a parking lane or low median, or 


16 


(7). 


no drivable surface, e.g., a drop-off, a barrier, etc. 



17 This adjacency attribute 140 provides information that enables a driver assistance 

18 system (44 in Figure 2) to determine an appropriate warning or operation relating to a 

19 lateral lane change. For example, the information provided by the adjacency attribute can 

20 be used to define where a lane change can legally occur. The information provided by 

21 the adjacency attribute can also be used to determine where other vehicles are likely to be 

22 present. 



23 There are several additional considerations relating to the way that the physical 

24 configuration data represents lanes. 

25 There is often (but not always) lateral connectivity between parallel lanes of a 

26 road that carry traffic in the same direction. For many roads, a vehicle traveling in one 

27 lane may change lanes at any point. This lateral connectivity is modeled with the 

28 embodiment disclosed herein. According to this embodiment, there may not be any 

29 particular points at which traffic can change from one lane to another, and the paths taken 
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1 by vehicles to effect lane changes may vary, depending on driver preference and 

2 influenced by speed and traffic conditions. 

3 Lanes can begin or end in the middle of a roadway, causing vehicle paths to move 

4 into or out of lanes. In the transitional areas where lanes begin or end, the physical 

5 centerline of the narrowing/widening lane may not correspond to a likely vehicle path. 

6 Moreover, the vehicle paths of cars entering or leaving forming or merging lanes is not 

7 necessarily predictable in many cases. 

8 Lane-specific attributes may change at any longitudinal point along a lane. 

9 Different lanes along a road may have attribute changes at different longitudinal points. 

10 The embodiment disclosed herein provides for these changes by defining sublanes that 

1 1 have attributes that supersede those of their associated lanes. 

12 In the embodiment disclosed herein, support is provided for representing the 

13 geometry of a lane more accurately than in conventional road databases. This higher 

14 level of accuracy may be required by some driver assistance applications. 

15 Another consideration associated with the representation of lanes in the physical 



16 configuration data 82 is that the representation should be reUably derivable firom practical 

17 source materials. For example, the representation of lanes in the physical configuration 

18 data 82 should be derivable from vehicle path data obtained from driving, overhead aerial 

19 imagery, or probe vehicle ("floating car") data. 
20 

21 V. REPRESENTATION OF INTERSECTIONS 

22 As stated above, the physical configuration data 82 also includes representations 

23 of intersections. Where roads intersect, the physical configuration data 82 models the 

24 relationships between the lanes that bring traffic into the intersection and the lanes that 

25 take traffic out. Modeling these relationships involves several considerations. For 

26 example, simply extending road lanes into an intersection area would lead to many lane- 

27 to-lane crossings that would imply connectivity between crossing lanes that may not be 

28 present in reality. In addition, if connectivity between lanes does exist, a simple 

29 extension of the lanes into the intersection area might indicate the point of the 

30 connectivity in the wrong place. For these reasons, as well as for other reasons, the 
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1 physical configuration data 82 in the road database 60 includes a road lane data model 

2 that has road lanes that lead up to, but not through, intersections. 

3 The following considerations are addressed by the intersection model used in the 

4 physical configuration data 82 in the road database 60: 

5 (1). The road-to-road maneuvers that take place at an intersection, between 

6 specific lanes on the incoming and outgoing lanes, are described. In particular, a driver 

7 assistance application — in a vehicle heading into and through an intersection — is 

8 provided with the information needed to predict a likely vehicle location at some time or 

9 distance offset fi'om the current vehicle position. 

10 (2). The fact that some maneuvers through an intersection have predictable 

1 1 vehicle paths, whereas other maneuvers through the intersection do not have a predictable 

12 path, is accommodated. 

13 (3). The interaction between traffic signals and traffic at the intersection is 



14 modeled. This modeling accounts for the case in which some traffic lanes or maneuvers 

15 are controlled by different aspects of the traffic signals (e.g., a left-tum signal). This 

16 modeling also accounts for the case in which some maneuvers at an intersections are 

17 governed by traffic signals and other maneuvers at the same intersection are not (e.g., a 

18 "Yield" on a right turn). 



19 (4). Normal intersections are distinguished from special types of intersections 

20 such as roundabouts and railroad crossings that pose special considerations for driver 

21 assistance systems. 

22 To support compatibility with navigation-related applications, the representations 



23 of intersections in the physical configuration data 82 are associated with the node data 

24 that represent the same corresponding actual physical intersections in the navigation data 

25 80. Some actual physical intersections are represented by more than one node data 

26 record in the navigation data 80. For example, an intersection between a multiple- 

27 digitized road and a single digitized road may be represented by two or more node 

28 records in the navigation data 80. In such cases, the representation of an intersection in 

29 the physical configuration data 82 is associated with all the node records in the navigation 

30 data 80 that represent the same intersection. 
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1 Another consideration associated with the representation of an intersection in the 

2 physical configuration data 82 is that the representation should be reliably derivable from 

3 practical source materials. For example, the representation of an intersection in the 

4 physical configuration data 82 should be derivable firom vehicle path data obtained from 

5 driving, overhead aerial imagery, or probe vehicle ("floating car") data. 

6 The above considerations are addressed in an embodiment of the physical 

7 configuration data 82 disclosed herein. 

8 As stated above, an iatersection object 100 is a data entity in the road database 60. 



9 In a present embodiment, the intersection object 1 00 does not define shape or determine a 

10 position. Instead, the intersection object 100 defines the logical associations between the 

1 1 other data entities that represent the various physical components of the actual 

12 intersection. An intersection object 100 is defined for each road-to-road intersection 

13 represented in the road database 60. 

14 Referring to Figure 6, each intersection object 100 is identified by a unique ID, 

15 (e.g., an intersection object ID 100(1)). 

16 Each intersection objection 100 is logically associated with (i.e., references) one 

17 or more of the nodes (by node ID) that represent the intersection in the navigation data 

18 80. Accordingly, each intersection objection 100 includes a reference 100(2) to one or 

19 more node IDs. By referencing the node IDs that represent the intersection in the 

20 navigation data 80, the intersection object 100 associates the representation of the 

21 physical configuration of the road with the navigation representation of the road network. 

22 Each intersection object 100 includes an attribute 100(3) that identifies the 

23 intersection type. The intersection type attribute 100(3) identifies the represented 

24 intersection as "standard," "roundabout," or "railroad crossing." Most represented 

25 intersections are "standard." An intersection Hke the one in Figure 7 (i.e., intersection 

26 200) would be represented as a "standard" intersection. 

27 Referring to Figure 6, the intersection object 100 includes a maneuver Hst 100(4). 

28 The maneuver list 100(4) includes entries for all the reasonable, legal transversals fi-om a 

29 lane entering the represented intersection to a lane leaving the represented intersection. 

30 For example, referring to Figure 7, the maneuvers fi'om three of the lanes 210, 212 and 
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1 214 entering the intersection 200 are shown. The lane 210 that enters the intersection 200 

2 has one maneuver 220 onto the lane 222 and another maneuver 224 onto the lane 226. 

3 The lane 212 that enters the intersection 200 has only one maneuver 228, i.e., onto the 

4 lane 230. Likewise, the lane 214 that enters the intersection 200 has one maneuver 232 

5 onto the lane 234. (For the sake of clarity, Figure 7 illustrates the maneuvers from only 

6 the three lanes 210, 212, and 214 that enter the intersection 200 from the road segment 

7 202. It is understood that the intersection object that represents the intersection 200 

8 would include all the maneuvers from all the lanes from all the rest of the road segments 

9 that enter the intersection.) 

10 Each entry in the maneuver list 100(4) in Figure 6 includes several kinds of data 

1 1 about the represented transversal. Referring again to Figure 6, an entry in the maneuver 

12 list identifies the entry lane 100(4)(1) and the exit lane 100(4)(3) for the maneuver. The 

13 entry lane and the exit lane are identified by lane data entity IDs. In the embodiment of 

14 Figure 4, the entry in the maneuver list 100(4) also indicates the segment of which the 

15 entry lane is a part 100(4)(2) and the segment of which the exit lane is a part 100(4)(4). 

16 In this embodiment, these segments are identified by road segment IDs (i.e., references to 

17 the road segment records in the navigation data 80). 

18 An entry in the maneuver Hst 100(4) also identifies the geometry 100(4)(5) of the 

19 maneuver. At a minimum, the geometry is identified as a straight line between the end of 

20 the incoming lane 100(4)(1) and the start of the outgoing lane 100(4)(3). If the entry and 

21 exit lanes physically meet (such as in the intersection 236 illustrated in Figure 8), the 

22 geometry 100(4)(5) indicates the single point where the entry end exit lanes physically 

23 meet. If the travel path of a vehicle between the entry lane and the exit lane is curved, 

24 this geometry 100(4)(5) may indicate this path by defining a parametric curve. 

25 An entry in the maneuver list 100(4) also includes a confidence indication 

26 100(4)(6). The confidence indication 100(4)(6) relates to the maneuver's geometry 

27 1 00(4)(5). The confidence indication 1 00(4)(6) indicates the likelihood that the geometry 

28 of the maneuver accurately predicts or represents a vehicle path. For example, it is 

29 possible that a basic straight-line connection between an entry lane and an exit lane is 

30 highly indicative of actual vehicle paths, such as when going straight through an 
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1 intersection. It is also possible that even for a turning maneuver, the vehicle path is 

2 highly predictable and well known. However, it is also possible that the vehicle path 

3 geometry through a maneuver is variable or even unknown. 

4 Figure 9 shows several possible paths, labeled 240, 242 and 244, that a vehicle 

5 could legally take when traveling from the left turn lane 214 on the road segment 202 

6 onto the lane 234 on the road segment 206. Each of these several possible paths is a legal 

7 path. The entry for this transversal in the maneuver list 100(4) in the intersection object 

8 1 00 that represents this intersection would include the geometry for only one of these 

9 paths. In addition, the maneuver entry for this transversal would have a low confidence 

10 indication 100(4)(6), i.e., meaning that the probability of the vehicle actually being on the 

1 1 path indicated by the geometry 1 00(4)(5) is relatively low. This confidence indication 

12 100(4)(6) is used by driver assistance applications (52 in Figure 2) to determine if a 

13 vehicle's deviation from the maneuver geometry is of concern. 



14 In a present embodiment, the confidence indication 100(4)(6) is set to one of 

15 several values. These values include the following: 

16 (1). None - When the confidence indication 1 00(4)(6) is set to **None", the 

17 geometry 100(4)(5) is set to indicate a straight-line connection. However, this straight 

18 line geometry is not intended to represent an actual vehicle path. 

19 (2). Instantaneous - When the confidence indication 100(4)(6) is set to 

20 "instantaneous", the incoming and outgoing lanes meet with no gap or cross-traffic. An 

21 example of an intersection with no gap between the incoming and outgoing lanes and 

22 therefore an instantaneous confidence indication, is shown in Figure 8. 

23 (3). Actual, high confidence - The confidence indication 100(4)(6) is set to 

24 "Actual, high confidence" when the geometry is based on accurate sources such as probe 

25 vehicle data with small statistical variance. 

26 (4). Actual, variable - The confidence indication 100(4)(6) is set to "Actual, 

27 variable" when the geometry is based on sources that indicate a higher statistical 

28 variance. 
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1 (5). Cartooned, high confidence - The confidence indication 100(4)(6) is set to 

2 "Cartooned, high confidence" when the geometry is typically, a straight-line connection 

3 for a straight-through maneuver between lanes that line up well. 

4 (6). Cartooned, medium confidence - The confidence indication 100(4)(6) is 

5 set to "Cartooned, medium confidence" when the geometry is digitized firom tire artifacts 

6 or other evidence that does not provide a statistical variance. 

7 (7). Cartooned, low confidence • The confidence indication 100(4)(6) is set to 

8 "Cartooned, low confidence" when the geometry is digitized logically but without 

9 supporting evidence. 

10 An entry in the maneuver list 100(4) also includes an indication 100(4)(7) 

1 1 whether the maneuver is the "most likely path" for traffic coming fi-om the associated 

12 incoming lane. This indication is meaningfiil when two or more maneuvers are possible 

13 firom the same lane. This will help a driver assistance appUcation (52 in Figure 2) 

14 determine a likely lane-level position. 

15 An entry in the maneuver list 100(4) also includes an indication 100(4)(8) 

16 whether traffic signals are present at the intersection and an indication as to which 

17 particular signal(s) govern traffic for this maneuver. It is possible that all maneuvers for 

18 a particular incoming lane will share the same signals, but it is also possible that 

19 maneuvers for different incoming lanes will be governed by different traffic signals. 

20 In addition to the information indicated above, the intersection object may include 

21 additional data. 
22 

23 Roimdabouts 

24 As mentioned above, an intersection objection 100 includes an attribute that 



25 indicates an intersection type. One of the intersection types is "roundabout." Having 

26 information that indicates that an intersection is a roundabout is usefiil for driver 

27 assistance applications that involve sensing the path ahead of a vehicle. When a vehicle 

28 enters a roundabout intersection, it follows a circular path in a single rotational direction 

29 around a center island of the roundabout. Thus, the vehicle entering a roundabout firom 

30 an entry lane may actually travel in a direction away from the exit lane as it travels 
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1 around the roundabout. A driver assistance application that senses the path ahead of the 

2 vehicle uses the information that an intersection is a roundabout to account for the vehicle 

3 path traveling around the roundabout. 
4 

5 Raibroad crossings 

6 As mentioned above, another type of intersection is a "railroad crossing." Note 

7 that an intersection indicated to be a **railroad crossing" is not necessarily an intersection 

8 of actual roads. However, in a present embodiment, railroad crossings are represented by 

9 intersection objects, in part because of the presence of metal rails that may be detected by 

10 in- vehicle sensors. 

1 1 A railroad crossing is similar to a road crossing in that the lanes may not be well 

12 defined through the crossing. A railroad crossing may present radar targets (not only 

13 trains but also metal rails), and may have marked stopping positions. 
14 

15 VL OPERATION 

16 As mentioned above, a vehicle that has a driver assistance system uses a road 

17 database that has road physical configuration data to provide safety or convenience 

18 features. On a continuous basis, a position of the vehicle relative to the road network is 

19 determined. This function is performed by a positioning system in the vehicle. Using the 

20 physical configuration data, the driver assistance applications can predict the path ahead 

21 of a vehicle as the vehicle travels along roads and through intersections. This allows the 

22 driver assistance systems to provide safety and convenience features as the vehicle travels 

23 along roads and crosses intersections. 
24 

25 VII. ALTERNATIVES 

26 One alternative embodiment pertains to the way that lanes of less than full width 

27 are represented. The above-described embodiments disclose ways to model lanes that are 

28 less than full width. Lanes that are less than full width include lanes that are forming and 

29 lanes that are ending (e.g., merging into another lane). According to some above- 

30 described embodiments, a lane that is less than full width is not modeled as a lane (i.e.. 
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1 with a data record), but instead is modeled as an attribute of an adjacent lane (or a 

2 sublane of an adjacent lane). In one alternative embodiment, lanes that are less than full 

3 width are modeled as lanes. According to this alternative, lanes that are less than full 

4 width are represented using lane data entities. In this alternative, data entities that 

5 represent these types of lanes include an attribute that indicates that the represented lane 

6 is less than full width (e.g., a "transitioning lane"). A data entity that represents a 

7 transitioning lane may include some or all the attributes of a full lane. For example, a 

8 data entity that represents a transitioning lane may indicate start and end points. A data 

9 entity that represents a transitioning lane may also include adjacency attributes. The 

10 adjacency attributes of a transitioning lane would indicate what features are located next 

1 1 to the transitioning lane. A data entity that represents a transitioning lane may also 

12 include a centerline. The centerline of a transitioning lane may be determined from the 

13 actual physical dimensions of the transitioning lane or alternatively the centerline may be 

14 estimated from the start and end points of the transitioning lane. 

15 Another alternative embodiment pertains to the representation of intersection 

16 maneuvers. In one of the embodiments disclosed above, it was stated that a confidence 

17 level is associated with the geometry of an intersection maneuver. For example, referring 

18 to again to Figure 9, there are several possible legal paths, 240, 242 and 244, that a 

19 vehicle could legally take when traveling from the left turn lane 214 on the road segment 

20 202 onto the lane 234 on the road segment 206. In the previously described embodiment, 

21 the maneuver entry for this transversal would have a low confidence indication, i.e., 

22 meaning that the probability of a vehicle actually being on the path indicated by the 

23 geometry is relatively low. In an alternative embodiment, the maneuver entry for this 

24 traversal may include an indication of a likely lateral deviation from the given path. For 

25 example, referring still to Figure 9, the maneuver entry for the traversal would indicate 

26 the geometry for one path (e.g., path 242) and in addition, the maneuver entry would 

27 specify a lateral deviation that would indicate the maximum distance from the path 242 to 

28 the path 240 or the path 244. The lateral deviation data would be in addition to or a 

29 substitute for the confidence level data associated with the maneuver entry. 
30 
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1 Vni. ADVANTAGES 

2 The embodiment of a road database, described above, and in particular, the way 

3 that the physical configuration data represents lanes, provides several advantages. The 

4 way that the physical configuration data represents lanes provides a level of detail that 

5 enables driver assistance applications (52 in Figure 22) to function. For example, the 

6 way that the physical configuration data represents lanes enables a lane departure 

7 warning system to function. In addition, the way that the physical configuration data 

8 represents lanes enables a forward collision warning system to function by providing the 

9 data the system needs to determine whether an object detected ahead of the vehicle is 
10 inside or outside the vehicle's lane. 

11 

12 It is intended that the foregoing detailed description be regarded as illustrative 

13 rather than limiting and that it is understood that the following claims including all 

14 equivalents are intended to define the scope of the invention. 
15 

16 
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